Amiga Plus 1996 #6/Amiga Plus CD - 1996 - No. 06.iso/pd/spiele/wgp/designersnotes

Text File | 1996-01-24 | 8KB | 125 lines

      In April 1992, I bought a copy of Avalon Hill's Third Reich for the
Amiga.  Boy, was I  disappointed!  There were no user interface "standards"
used in the program, no sliders or menus,  and the four color palette was
pathetic on a 4096 color machine!  It was a very sloppy piece of  software,
but with all its shortcomings, it would have still been useful -- except
that the only  place you couldn't save a game was between user turns!

  I decided that I could do better, if I knew how.  At the time I had been
using Amigas for  two years, and was still a "user."  I cast about for the
better part of a year looking for a language  that I could understand, when
I bought a copy of Innovatronics' CanDo 2.0.  I was ecstatic at the  ease
with which things came together in this system, and in the space of a
couple of months had  designed a play By Mail engine for the old Avalon
Hill classic "D-Day."  I wasn't going to make  the same mistake AH had by
attempting a prototype on a very complicated game.

    My D-Day module was tailored specifically for that game.  It used 12
quarter screen  "plates" for the map,  and really stretched the graphic
limits of CanDo beyond what the designer's  intended, I think.  I was very
proud of this and sent a copy to AH.  I was hoping to get into a
partnership with them where I would put together modules of each of their
games for them.  AH  liked the idea, but they only had a vanilla A500 with
a meg of RAM: and, sadly, my program  needed a minimum of 2.5 Megs (CanDo
is not real big on memory management).  I went back to  the drawing board
and did everything I could to crunch the program down to size, but the only
 was to do so was to emasculate the program.  This dilemma was solved by
Innovatronics, when  they announced an insane policy that any commercial
product developed with CanDo would owe  royalties to Innovatronics
(good-bye, CanDo, from the serious Amiga community).

     So my ideas went back into hibernation when a friend turned me on to
Amos.  After an  initial surge of development, I ran into some conceptual
snags, and lost interest in the program  for long periods of time, or was
wrapped up in other programming endeavors.  It was mid-1994  before I had
re-completed my original D-Day module, this time in a program that would
run in  under a meg.  I contacted Jim Rose at AH to see if I could re-light
some interest.  My first approach to AH in 1993 had a very warm reception,
and they were willing to listen to what I had to  offer and were eager to
see it, so I wasn't uneasy about going back to them, this time with a
product that worked.  I was very taken aback, when I got a very abrupt
reception, and Mr. Rose was --  almost -- out and out rude to me.  After a
very short conversation in which I had very little to say,  I hung up and
wasn't too keen on calling back.

  So I said to heck with it.  I would design my own games and market them.
I couldn't use  this software with someone else's game and get any money
out of it without dealing with copy- rights, etc., but by golly, I could do
my own game!  I embarked on a project called "France-44"  I  redesigned the
map using the CIA world data base, and wrote a large amount of code to
enforce  movement, supply, Zones of control, and other game functions.
Then I hit a conceptual snag  (again) and the program went back in
hibernation in late '94.  But this was a monkey on my back,  because I was
so close to having a really usable program!

     Then in early March of '95, I was monitoring the Aide de Camp topic
on-line, when  someone made a comment like "when will it be out for Amiga?"
 Something clicked in my head,  and I quickly went back and reviewed
everything I knew about AdC (which wasn't much).  I finally got ahold of a
press release that listed the major features, and realized that most of
this code  already existed in one form or another on my machine!

     I went to work immediately, and in the space of a week had roughed out
all the major  functions of the editor.  Then I went back with a chainsaw
to my original code and started throwing things out and reworking the
player to accept a more dynamic definition of a game, and concentrated on
the PBM interface.  The result was bearing edible fruit within 3 months.

     A recurring question has been "when will you install an AI opponent?"
The answer is:  never.  AI technology has not progressed far enough to make
it worthwhile developing an opponent which would interest a human player.
This is based on several precepts.  I would not develop an AI that
"cheated" nor an AI which relied on handicapping the human player to be
challenging.  I dislike games which do this, and refuse to do it myself.  I
have publicly offered a $100  wager to any takers that at least 80% of
experienced players will beat AH's PC3R (if it ever  ships) the first time
they play.  To date, I have no takers.  I have played several computer
games  via modem/null-modem, after which I found computer opponents to be
boring and not worth my  while.  With this experience behind me, I decided
that my resources would better spend developing a user-friendly
play-by-mail system.  A painless PBM capability would obviate the need for
an AI which could only be a far second-best to a human opponent in the best
of circumstances.

     Another request has been modem capability.  This is a feature which
many will ask for  and few will use more than once.  I once played a
Perfect General "tournament" by modem.  It  was quite fun, but even though
this game is very interactive as games go, for the non-phasing  player it
was only slightly more interesting than watching paint peel.  If you
consider that a  full-blown turn of Third Reich or World in Flames could
take more than an hour for one player  to decide what he's going to do and
do it, it wouldn't take long before the non-moving player  would say "Hey,
why don't you call me back when you've finished, eh?  I'm going to go play
with the kid's mama while you move!"  The sort of games that will lend
themselves well to this  system are the kind where you want to spend a day
or so considering strategy, hand your opponent a copy of "War and Peace"
and tell him to get lost for awhile.

    Since the initial release of the WarGame Processor, I have received
some feedback and comments, as well as some considerable experience in
designing modules, all of which has gone into the revisions I have
incorporated in this latest version.  The WGP is hex based but can easily
be adapted to games like "Breakout: Normandy!"  Take a look at the Victory
in the Pacific module if you want to see how area-style games can be dealt
with.

    I have been using WGP to play several enjoyable games of Third Reich
and Advanced Third Reich cross country by E-mail.  Many of the shortcomings
of earlier versions were corrected through this experience, as well as
ideas for new features such as the encrypted comment feature.

    I'm also working closely with one of my beta testers in Canada and a
local ASL group to develop ASL compatibility with WGP.  The key to this
thorney problem is to use oversize hexes on the WGP map, with the displayed
hexes encompassing seven WGP hexes.  Then the individual tasks, levels, or
stacks in an ASL hex can be represented by different places within the
shown hex.

I am currently working on WGP V2.0.  This release will be completely
rewritten in C to conform to the operating system.  The program will be
basically the same in as many aspects as I can manage.  It will be
mode-promotable on AGA machines, and compatible with WB3.1+.

Sean Emerson
Somewhere East of the Mississippi (for now)
August 95